Cream of the Crop 3/Cream of the Crop 3.iso/comm/aprs403x.zip/README.BBS

File List | 1994-01-19 | 8KB | 120 lines

       USING PBBS's AND INCLUDING APRS PROTOCOLS IN BBS and NODE SOFTWARE

    One thing we have learned in maintaining an operational APRS net on 145.79,
is that it is very useful for all stations to include in the comment field of
their position report the address of their home BBS!  Then any station on the
APRS frequency immediately learns how to send that station a lengthy packet
message.  If your TNC supports an internal BBS, it is also useful to leave it
on and include its unique address or SSID in your comment field so that stations
can access your PBBS even while you are running APRS!  A few stations sending
keyboard messages into a PBBS on the APRS frequency is not objectionable since
the number of packets are small and at typing speed.  Also, by having personal
mail boxes, users then DO NOT read their mail over the air!  I encourage all
stations to operate their own PBBS maildrops on the APRS frequency; but please
do not use the PBBS's to post messages for others who must read the message
over the air.  All stations should avoid any other general computer to computer
exchanges which would block the frequency for large blocks of time.

    The remainder of this file is intended for BBS SYSOPS and the writers of
BBS and NODE software.  Please consider the following advantages to including
APRS protocols in your station operation.  Since APRS allows stations to see
the network topology in real-time, it is ideal for determining the locations
of all neighboring BBS's and NODES.  If BBS's and NODES simply included either
the LAT/LONG or GridSquare in a periodic UI frame, all users could see where
the system is located.  For permanent  sites such as BBS's and NODES, this
beacon could probably be transmitted once every hour or so.  As of APRS version
2.08 the !LAT/LONG format can be placed anywhere in the BText.  This was to
accommodate THENET Nodes and some BBS software where the beginning of the BText
is pre-loaded with something already and the !LAT/LONG can only be appended to
the end.  The exact format of the UI frame should be as follows:

    BBSXX>APRS:!DDMM.xxN/DDDMM.xxW[comments as desired to end of line
    BBSXX>APRS:[GRidsq]Comments to end of line

    For BBS code writers, this process can be enhanced by making the BBS respond
to APRS Query packets.  One of these packets is transmitted whenever an APRS
station initializes his program.  On receipt of an APRS Query packet, all
stations on frequency set a two minute random number timer and respond sometime
in the next 2 minutes with their location.  This way, any APRS station can
obtain the location of all stations on the frequency soon after comming on
frequency.  The format of the APRS Query packet is W4XYZ>APRS:?APRS?.  By
including the code in NODE and BBS software to respond to APRS Querys, the
periodicity of the APRS position beacon can easily be set quite infrequently
since stations can request the BBS position at any time.  For those concerned
with physical security, the grid square position report can be used which is
ambiguous to 3 miles or so instead of the LAT/LONG posit accurrate to 60 feet.

    I have one other request to BBS SYSOPS.  Since APRS contains a BEACON
parser to display to users all BEACONS heard on frequency, this is an excellent
way for stations to capture MAIL-FOR beacons.  APRS stations simply call up
their LATEST BEACONS display and see if there are any BBS's reporting mail for
them.  Unfortunately, the parsing algorithm in APRS only recognizes BText which
occurs on the same line as the packet header.  MAIL-FOR which is listed on a
second line after the header do not show up in the APRS system.   For this
reason I would like to request BBS SYSOPS to modify their MAIL-FOR beacons to
keep the beginning of the MAIL-FOR list on the same line as the packet header.
By allowing APRS stations to see mail lists without even logging on, you are
helping reduce congestion on the channel.  Presently, most stations do not see
MAIL-FOR beacons because they scroll off the screen too rapidly.  APRS grabs
all packets that are TO the following addresses: APRS, BEACON, ID, MAIL,
SKYWRN, CQ, and QST.  APRS retains the last of these heard per station.  APRS
can also be told to monitor all OTHER packets with the ctrl-O command.

     Please play with the APRS software and load some of the backup and
demonstration files included.  I'm sure you will find APRS to be an exciting
new capability for packet radio which can make packet radio much more responsive
in real-time communications.

     Finally, ambitious code writers could add code in their BBS's to capture
all APRS position reports heard on frequency.  These reports could be retained
in a file and be made available to local users.  One of these files, if
downloaded, can be loaded by APRS users to display the locations of all stations
ever heard on the frequency!  Talk about preparations for emergency comms!

BBS FORWARDED POSITION REPORTS:  Since we already have a worldwide packet
network of BBS's which have the ability to forward a packet message anywhere
in the country, I would like to see a standard message format built which would
permit a mobile, roving packet station to report his location back to his home
BBS on a once-a-day type basis.  Imagine that this mobile station simply posts
a message on any nearby BBS which contains his position and the routing for his
home BBS.  That packet message would be forwarded via the normal BBS network
and arrive at the intended destination whereupon the destination BBS would in
turn send out a decaying APRS beacon reporting that unit's position even if
he was thousands of miles away and on the road!  All of his buddies (or his
wife) would see on their home computers his latest position automatically which
was actually relayed through the packet BBS network.  As with any APRS position
report, the beacon periodicity would decay from 10 minutes to once every few
hours as the position report got older.  The format for such a position report
for WB4APR might be as follows:

Send:    SP APRS @ W3IWI.MD.USA                   Send command with Routing
Subj:    !3858.11N/07629.11W/040/010              LAT/LONG/CSE/SPD
Msg:     Be home at 1200 Saturday.                Comment field up to 40 chars
         /EX

On receipt of such a message, the receiving BBS (W3IWI) would form an APRS
station reporting UI frame and transmit it periodically as follows:

W3IWI>APRS:WB4APR   @051937/3858.11N/07629.11W/040/010/Be home at 1200 Saturday

As with all APRS packets, this packet would be transmitted once, then 32 seconds
later, then a minute later, then 2 minutes later, and so on.  This doubling
ot the packet period after each transmission decays very repaidly to only 5
packets in the first 10 minutes, 3 more in the next hour and only 3 more in an
entire 24 hours!  Since the packet took hours to get to the BBS in the first
place, it might be more appropriate to start off with an initial period of one
or two minutes.  This is not such a load!  This would only be 9 packets in the
first day and only 1 in the second!  When the period is greater than 24 hours,
the message is deleted from the system. People on the road reporting home would
probably send a new message every 24 hours anyway.


BBS POSITION DATABASE:  Since APRS includes an individual station query
capability, a BBS that has accumulated the position of all of its users, could
respond to such an APRS query with a one time position report for that station
without even logging on.  The APRS query is simply a one line APRS message from
the querying station to the Queried station with the letters "?APRS" in the
first 5 character positions.  A BBS seeing such a packet could respond
immediately with a position report for that station!